Hey Chris, thanks for sending this. We should add a comment but strip_include_prefix is there for a reason: #837 (comment) When setting up these build rules we found a bunch of cases where Bazel exposed "private" headers to downstream targets and I'm reluctant to change anything here as my understand has only gotten rustier since then.

As far as I'm aware, this change will mean that downstream targets that use #include <stacktrace.h> might pick up glog's internal header rather than their own headers as they expect. Unfortunately, I'm not aware of a good way to test for this (until thinking about it just now, I'd thought we'd need an external repository, although maybe we could have a test within this repo that does #ifdef #error for a header defined in stacktrace.h...). Can you check whether this PR will change that behavior?

Hey, Rodrigo! Indeed it would. Great, subtle catch. Thanks for defending the functionality, and also for being nice about it. It hadn't struck me that one might use the individual symlinking of _virtual_includes to get bazel to enforce the header inclusion restrictions Bazel otherwise doesn't without --features=layering_check. Agree that it's probably worth a quick comment, since it's depending on an implementation detail, but it is both important and clever! Anyway, closing down this ham-handed attempt at helping out.

Thanks again for your careful eye!
Chris

P.S. After a little more thought, I suppose another approach might be to switch to header names that clearly don't collide with system ones--and therefore resolve some other ambiguities, but I should probably bow out.